fix(network): own GetBlocks reservations through request writes - #944

reset_above upgrades weak request-write entries while holding the global WorkQueueInner mutex, but its iterator retains only claims whose range extends above the new floor. An upgraded claim rejected by that filter is dropped before the mutex is released. If the transport concurrently drops the previous last strong reference because a paired stream is cancelled, its write fails, or its write future is aborted, the filtered temporary can become the final Arc<RequestWrite>. The resulting non-WRITTEN destructor calls back into WorkQueue and attempts to acquire the same non-reentrant mutex, permanently deadlocking the reset. This can occur for any queued or partially written request whose range is already at or below the reset floor.

A destructive reset does not fully retire an unreceived request whose range includes the new floor. reset_above resets claims only when their last height is strictly above the floor and removes only queue entries strictly above it, so a request ending at the reset height can still start and a straddling request retains its prefix. When the peer routine observes the reset epoch, its generic cleanup returns those retained reserved entries to pending without enforcing the queue’s height > floor invariant. The next fill starts its search at the untrusted peer-advertised servable_low, so the stale reset-height entry can be selected and requested again. With the default one-block request geometry, a peer can repeatedly return a short response for that obsolete height, keeping the scheduler from reaching the first needed successor.

A published GetBlocks request can already be in the transport’s STARTED state when the peer routine exits. PeerRoutine::drop nevertheless returns every unreceived height to pending and releases its byte charge without first retiring the request stream. Queue cleanup calls only expire_unwritten, which cannot stop a claim after it has transitioned to STARTED; only the reset-specific path cancels such a write. A peer can trigger this by sending a malformed inbound frame after the outbound writer starts the request: the protocol error drops the routine before the outer supervisor cancels the connection, allowing the original write to complete after its work is reissued and uncharged.

RequestWrite::reset attempts to retire a partially written request by cancelling the block-sync session when its state is STARTED. Block sync is registered as a single ordered stream, so the transport runs it under the standalone write policy rather than as an interruptible ordered pair. The standalone worker explicitly disables its stream-token cancellation arm while the current frame write is pending. A reset racing the request write therefore cannot stop the invalidated GetBlocks frame, and a successful write subsequently records the claim as WRITTEN. The peer can then serve an obsolete range after its local work has already been released or replaced.

A replacement peer routine starts with received_status = false and refuses all download work until it receives a new Status, but session admission preserves the previous registry entry’s status, servable range, latency score, and slot diagnostics while only bumping its generation and clearing outstanding heights. The superseded routine’s generation-gated teardown cannot clear those preserved eligibility facts. Other routines continue consulting the stale registry entry and defer the floor whenever it appears to be a faster unsaturated carrier. An authenticated peer can first establish a favorable RTprop and free-slot state, replace its block-sync session, and then withhold Status; its new routine never requests the floor while all slower honest routines keep yielding to it.

Late responses for heights that have been reassigned to another peer bypass both defenses that reconcile untrusted size estimates with actual body memory. The normal matched path rejects a body whose serialized size exceeds the configured tolerance around its estimate, but the unmatched active path never performs that check. It also applies admit_received_body only when the height is pending, not when another request currently reserves it. An attacker can arrange low advertised estimates, let its requests time out and be replaced, then deliver maximum-size late bodies; the code releases each replacement’s small reservation and forwards the full decoded body despite a saturated resident lookahead gate.

The floor-selection code computes the critical missing successor as download_floor + 1 but asks the peer registry whether another peer can serve download_floor itself. At genesis or a pruning boundary, normal peers commonly advertise servable_low equal to the missing successor and therefore fail the preference test for the already-downloaded floor. A cold attacker can race a proven lower-latency peer for the exclusive successor request even though it should have deferred. Because an unmeasured peer now receives the normal timeout rather than the short rescue leash, each silent identity can hold the floor for the longer deadline. Rotating identities can repeat the delay.

The liveness grace for a full outbound queue is intended to be bounded, but no state records that a peer has already consumed it. Whenever the queue briefly regains capacity, the run loop clears outbound_full_since; filling it again shortly before the next liveness deadline makes the congestion interval appear fresh and grants another full request_timeout extension. A peer controls this by alternating reads and pauses and by sending GetBlocks messages that cause the node to enqueue serving responses. Repeating the cycle prevents the no-progress park indefinitely without returning an accepted block. The attacker can retain peer slots and protect other long-lived claims from the peer-wide liveness backstop.

An expired request can finish writing after its heights have been reassigned because timeout cleanup calls only expire_unwritten, which cannot transition a STARTED claim and does not cancel its session. The old and replacement requests can then share the same start_height. Stream-6 terminators contain no attempt identifier, and local lookup correlates BlocksDone and RangeUnavailable only by that start height. A delayed terminator generated for the expired request is therefore applied to the live replacement and returns its work using the replacement owner. A peer can repeat the sequence around transport backpressure to cancel valid retries.

A late response can settle a replacement owner while that replacement’s frame is still queued. RequestWrite::try_start correctly skips the frame because its reservation is no longer Reserved, but owner_for_height continues returning its owner as long as the item is non-provisional. Both obsolete-request GC and registry publication use this weaker owner predicate, so the never-written request remains locally and globally outstanding. It later times out, is counted as a reliability failure, and can park a healthy peer that never received a GetBlocks request. A malicious late responder can use timing to attrit competing carriers.

After the floor watchdog retires a height from shared ownership, the old peer routine can still hold a local range containing it. If that old peer’s valid started or written response arrives after another peer has reserved the height, range lookup takes the stale local match first, so the unmatched first-completion-wins path is never reached. The owner mismatch then drops the stale local request and returns without forwarding the already received valid body or settling the replacement. The node waits for the replacement’s full timeout even though it had a valid candidate available. A malicious replacement can deliberately withhold its response to maximize the delay.

Configuration validation imposes only a one-millisecond lower bound on request_timeout and no maximum. Cold floor requests now deliberately use that full normal timeout, while peer liveness multiplies it by four and deadline code adds these durations to Instant with unchecked +. A representable but extremely large value can let a silent peer hold the floor for years. A still larger accepted value can exceed the platform’s Instant range and panic peer routines whenever they arm a request or liveness deadline.

Partial retirement of a multi-height request is incorrectly interpreted as retirement of its entire outstanding range. The floor watchdog clears and returns only its current expired height, while advance_floor deliberately removes only a committed prefix and leaves a live suffix reserved. If a body then arrives for the retired height, owner_for_height no longer matches the range owner, and the peer routine calls drop_obsolete_outstanding for the whole local request. That removes the local timeout and published outstanding bookkeeping but does not return or otherwise settle the suffix entries that remain in in_flight; after RequestWrite reaches WRITTEN, its destructor also performs no settlement. The handler must distinguish a per-height retirement from retirement of the whole request, retaining/reconciling the live suffix and its liveness metadata, or explicitly return every remaining owner-owned suffix height when retiring the range.

Floor-claim deadlines are derived from a cumulative byte estimate that includes both earlier outstanding requests on the ordered stream and every block in the newly created range. Although normal serving sends the range contiguously from start_height, the deadline charges later range bodies that need not arrive before the critical floor body. Further, request_deadline selects the short floor_rescue_timeout only when a byte-rate measurement exists, while bbr_btlbw_bytes_per_sec returns None in CwndUnit::Blocks, causing floor claims in that mode to use the normal timeout. The resulting deadline is not bounded independently of request backlog or configured in-flight capacity, and the floor watchdog defers recovery until that stored deadline. Meanwhile, note_block_progress renews peer-wide liveness for any accepted block, letting a peer provide non-floor or later-range bodies while retaining an exclusively claimed floor height.

The first-completion-wins handling lets a late response release the active replacement request's per-height reservation based on height and the header-derived block hash, while transaction/body consistency is deferred to consensus apply. Since Hash for a Block is derived from its header, that check does not establish that the supplied body satisfies the header's commitments. The late response is forwarded and credited with progress and reliability before that semantic validation occurs. Once the reservation has been released, a subsequent response from the replacement peer follows accept_already_settled_height, which marks the height received and records progress without forwarding its body for validation. Consequently, an invalid late body can both win over a valid replacement and allow either the late sender or the replacement sender to receive liveness credit despite no validated block having been supplied; recorded misbehavior does not cancel the session.